JAWS SUMMIT 2012

福田寅成

2012.03.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。くろの（福田）です。

先日、JAWS SUMMIT 2012第1日目に参加してきました。

■開催概要

日時：2012年03月02日（金）、03日（土）
場所：ベルサール六本木
主催：AWS User Group Japan (JAWS-UG)
Webサイト：http://jaws-ug.jp/summit2012/
ハッシュタグ：#jawsug

■オープニング：Welcome to AWS Eco-System: AWSとデベロッパーエコシステム

アリエル・ケルマン（@akelman） Director, WW Marketing Amazon Web Services

Cloud Virtualization + Application Services + Ecosystem Services
JAWSUG、2009年Kick Off、2010＋4、2011年+12（うち女子会1）
地理的拡大8つのリージョン
AWS Pace of Innovation：非常に速いイノベーション。2011年82サービスの追加
Amazon S3 Usage：2011年Q4、7620億個
Price Reductions：価格の低減
AWSの（Adoption）普及：米シェア59%
日経Cloud Ranking：AWS1位

AWSエバンジェリスト初号機玉川さんからのお知らせ

元gumi CTOの堀内さん（@horiuchi）がAWSのテクニカルエバンジェリスト弐号機に！

■キーノート1：Build your own apps on AWS: AWSでクラウドデベロッパーになろう

ジェフ・バー（@jeffbarr） Senior Evangelist, Amazon Web Services

▼2011年の新しいAWSリージョン

2011年3月Tokyo
2011年8月GovCloud＝米政府、州、関連企業専用クラウド
2011年11月Oregon
2011年12月Sao Paulo（サンパウロ）

今後各国政府専用クラウドも作っていきたい！

▼AWS Elastic Beanstalk

Javaアプリケーションを用意するだけで環境は自動的にAWSが作成してくれる。
今後他の言語にも広げていきたい（！）
AWSリソースを直接コントロール、カスタマイズすることも可能

▼Amazon Virtual Private Cloud

Dedicated Instances：占有インスタンス（1物理サーバー内に1ユーザーのサーバのみ）

▼Amazon DymanoDB

低遅延
シームレスな高スケーラビリティ
冗長性、可用性
管理不要
プロビジョンド・スループット
- IOPSを設定＝保証
- 必要なスループットを予め設定
APIで設定を変更可能
IOPSが閾値を超えた場合の通知機能アリ

■キーノート2

The Challenge Economics of Data: アマゾン内の事例にみる、ビックデータとクラウドの活用最前線

ジョン・ラウザー（@jrauser） Principal Quantitative Engineer, Amazon Web Services

▼amazon.com社内チームにインタビュー

new economics（Hadoop、Cloud Computing）
lower cost
distributed computing is hard

★2台のコンピュータで処理を行うようになると、難易度は突然上がる★

例えば人の作業時間の平均を取る。 Aさん 9:00 9:10、Aさん 11:31 11:58の様なデータ

map：人作業時間
shuffle：ソート
reduce：合算

この合算処理は異なるマシン（クラスタ）によって行われる。全体では複雑な処理もシンプルなタスク（mapとreduce）に分割する事が重要。

このmapとreduceの処理を「安価なハードウェアで実現」出来るようになった。

amazon.comではすべての製品カタログをAmazon S3に保存。10億以上のアイテム。変更の少ない処理は2ノードのAmazon EMRで処理。全カタログの分類は50ノードのAmazon EMRで処理。

このクラスタノード数が多様なのが特徴。スモールとかビッグとかによってシステムが変わるわけでなく、同じような処理を異なるノード数のEMRで処理しているだけ。

（先ほどの図にあるように）処理の難易度はサーバー2台も50台も変わらない。

このノード数の決定が処理を行う直前であればあるほど良い。直前に決定できるようなシステムで有ればあるほどよい ⇒ 意思決定にどのくらいのスピードで対応できるかに繋がってくる！

speed limits risk

Amazon EMR lowers changes the economics of big data

What is big data?

Extremely Big Data = Peta, Exa?

処理サーバー数が非常に多くなると処理難易度はまた難しくなる。

しかし、Amazon EMRがそのデータ処理の敷居を大幅に下げてくれた。

amazon.com的にはsmall dataもextremely big dataも同じ難易度で分析できるので、特にどれが重要と言うことでは無い。すべて重要！

log processing isn't our business 残りの時間をお客様のための革新的なことを考える時間に回せることが重要

amazon.comは内部でAWSを使っているよ！

■アジャイルとクラウドが変える開発スタイル

司会：AWS玉川さん
パネラー：平鍋さん（@hiranabe）、倉貫さん（@kuranuki）

▼アジャイル

昔の開発：スポンジケーキ＞クリームを塗る＞苺を置く
今の開発：ショートケーキを作る＞必要な数を改良（スケールアップ）・量産（スケールアウト）していく
クラウドはショートケーキのスポンジを提供するので、その上のものを我々はアジャイルに開発していけば良い

今時はケーキ屋さんもショートケーキ毎に実際に作っているらしい（在庫を最小化している）

アジャイル開発＝ビジネスアラインド開発(aligned)

在庫を少なくしたい、持たない＝lean思考

▼クラウド出現のインパクト

デベロッパーのためのAWSクラウド

2006年AWS出現
amazon.comのデベロッパーの生産性を高めるために作られた。
社内タスクフォース
「サーバーをすぐに使いたい」
「ストレージをすぐに使いたい」
「これは社外でもきっと役に立つだろう」

プログラマブルなインフラストラクチャ（APIをコードでたたけばインフラを構築できる）

ハードウェアがソフトウェアに（作ったり、消したり、編集したりが容易に可能）

▼AWSクラウドと新ビジネス

ソフトウェアビジネス ⇒ （Web）サービスビジネス
10年前：オープンソース ⇒ ソフトのライセンス費を90%削減
最近：AWSクラウド ⇒ インフラの運用費を90%削減

▼アジャイル×クラウドの体現

point of sales ⇒ point of use

SIは製造業からサービス業にやっと変わってきた。サービス利用後も価値を上げていくスタイル。（製品＝販売（納品）時の価値が最大で、その後価値が減っていく（償却していく））

スモールスタートとスケールアウト（）従来は矛盾していたが今は自然な開発スタイル。（：クラウドアーキテクティング原則の一つ）

▼フリーディスカッション

AWSは落ちるもんだと考えて設計するのが良い。（品質に関する考え方を大きく変える必要な場面がある）

IPA非ウォーターフォール研究会電器メーカー、SI、楽天、GREEなどが参加。ビジネスが動いているところは自然にアジャイルを採用している。なのでエバンジェリズムする必要が無いのでは無いか？

クラウドの登場によって日本の産業構造がもう少し速く変化していくのでは無いだろうか。

アジャイルだとお客様と接する機会が増える。するとエンジニアのモチベーションが上がる。エンジニアの成長スピードも速くなっている。『高速道路化』している。

将棋がインターネットの登場によって進化スピードが劇的に上がったのと同様。

システムの完成形の話をすること自体が間違っている。（見えないゴールに対して顧客と一緒に少しずつ前進していくのが大切）

ここで、まつもとゆきひろ様光臨

言語＝道具、好きなの使って下さいが基本。

思ったことがぱっとできる言語が理想。言語周辺の環境も重要（ライブラリ等）

クラウドにより「言語のコアの部分」は影響を受けない。

インフラが安くなってるのに、ソフトウェア開発がそんなに高くていいの？ ⇒なので小さいチームでさくっと作って、よかったら育てていく流れ

▼まとめ

玉川さん：操船術が大事ぜよ
平鍋さん：3Kを3Tに。楽しい、定時に帰れる、高い給料
大貫さん：お金を稼ぐためにリーダーにならざるを得ないような環境を無くしたい。ソフトウェアは小さい会社で小さいチームで。それで大きな成功を。大きな会社いらんぜよ。脱藩せよ。

■ビッグデータ×クラウドが変えるシステムアーキテクチャ

司会：AWS大谷さん
パネラー：国立情報学研究所佐藤一郎さん（@ichiro_satoh）、NAUTILUS 神林さん

■ビッグデータ×クラウドが変えるシステムアーキテクチャ

国立情報学研究所佐藤一郎さん（@ichiro_satoh）

▼ビッグデータが流行っていますが

データ量や多様性が本質的では無い。
- そもそもビッグデータを持っている企業は少ない。
ビッグデータ関連技術が重要。
- スモールデータ処理の高速化。
スモールデータとビッグデータに本来境目は無い。
- 両者を接続する技術が重要。

今までの処理がコース料理、ビッグデータの世界はビュッフェ形式。いかに組み合わせるか。この組み合わせる処理が難しい。

データの前処理が大変。例：データ形式の変換

前処理に自前システムを使うのもったいない
※この前処理が出来ていれば実はRDBでも分析できるケースはある

▼アプリケーション主導からデータ主導へ

設計だけでなく、運用も含めてデータ主導

▼データ主導型システムアーキテクチャ

既存ITシステムは特定アプリケーションを前提に設計・適用
ビッグデータではデータと関心事に応じて分析手法を変える必要がある
なのでAWSを使うのが良い

▼クラウドが変えるシステムアーキテクチャ

中規模以上のITシステムは分析システムとして構築するしか無い
プロセッサコアの性能向上は頭打ち
コア数またはサーバー数を増やす

▼分散システムは複雑＆低信頼性

物理的制約（通信遅延）により、システムの全体情報が分からない
故障を想定したシステム構成・運用
「壊れたコンピュータ」と「いずれ壊れるコンピュータ」しか無い

▼ITシステムに縛られない

自前で分散システムを所有・運用すべきで無い。
- 分散システムの難しさは専門事業者（AWS）に任せる。
データやアプリケーションに応じたシステムアーキテクチャ。
- 汎用的なアーキテクチャよりも、目的に応じたアーキテクチャ。
- システム構成の動的変更はまだまだ研究レベル
スケーラビリティよりも伸縮性（Elasticy）
- 必要になったら拡張、【不要になったら縮小】
人に縛られない
- 開発者や管理者に仕事を作るためのITシステムはいらない。
- 人を雇わなければ人に縛られない。